fix(transport): flush stale input on recovery reset#21
Merged
Conversation
After an M112 the board emits `Error:Printer halted. kill() called!`. On the next connect that stale line was consumed by _establish_ready and misreported as a fresh halt, so reset-and-reconnect recovery failed. Add an opt-in `reset(flush=True)`: drop the input buffer right after the reset edge, discarding the already-buffered stale output while the post-reboot `start` (which arrives later) survives. Validated on a real RAMPS 1.4 / Marlin bugfix-2.1.x board — e-stop then reset(flush=True) + connect now recovers cleanly. Default stays non-flushing so a normal open still matches `start`.
CameronBrooks11
added a commit
that referenced
this pull request
Jun 28, 2026
Establishes the mock/hardware separation for the test suite:
- Default suite stays 100% hardware-free. New conformance corpus
(tests/conformance/*.trace) holds sessions captured from a real RAMPS
1.4 / Marlin bugfix-2.1.x board, replayed via FakeTransport.from_trace
in test_conformance.py — pinning connect/M115-negotiation and streaming
against genuine wire output with no board attached.
- New opt-in hardware lane (tests/hardware/, @pytest.mark.hardware) runs
live connect/query/stream/e-stop-recovery against a real controller.
Gated in conftest.py: collected but skipped unless --port is given, so
CI and offline devs never need hardware. Run with:
uv run pytest tests/hardware --port /dev/ttyACM0
Validated: default run 110 passed / 4 hardware skipped; the live lane
passes 4/4 against the real board (incl. the #21 e-stop recovery).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem (found during hardware bring-up, #4)
First real-hardware session (RAMPS 1.4 / Marlin
bugfix-2.1.x, no 12V) validated connect, M115 negotiation, reliable framed send, streaming, and pause/resume cleanly. The e-stop recovery path failed:The DTR reset did reboot the board, but
reset()deliberately doesn't flush, so the staleError:Printer halted(buffered from the M112) was the first lineconnect()read — and_establish_readycorrectly treats a fatal line as a halt, misreporting the freshly-rebooted board as halted.Fix
Opt-in
SerialTransport.reset(flush=True): after the reset edge, drop the input buffer. The stale output is already buffered (discarded); the post-rebootstartarrives after the boot delay (survives). Default stays non-flushing so a normal open still matchesstart.Validation
Re-ran the bring-up with
reset(flush=True)→ 6/6 phases pass on real hardware:Unit regression:
test_reset_with_flush_discards_stale_input_after_the_edgepins flush-after-the-edge ordering (pyserial mocked, no hardware).